Hey @amesgen @tbagrel1

The PR still needs a lot of work, but I think it would be good to get some early feedback on 7212954. I pushed a bunch of changes adapting call sites to use ValidatedPerasCerts whenever needed, as implied by the two TODOs left in 3425d67:

• Adapting PerasCertDB.addCert to take a ValidatedPerasCert, and
• Adapting ChainDB.addPerasCertAsync to take a ValidatedPerasCert

Based on my current understanding, there is a tension between keeping either PerasCerts or ValidatedPerasCerts around, depending on what we want to enforce:

1. Validating certs early on, and using those everywhere

• Somewhat better assurance that we don't ever try to operate on potentially-invalid certs
• Potentially useful in the cases where the extra evidence they carry allows us to avoid recomputing stuff (e.g. the block's boost)
• Needs a "big" refactor to adapt all call sites, including the "generation" of the now needed validation evidence in some property tests

2. Validating certs when needed, but using the original PerasCert everywhere

• Might open the door for bugs caused by operating on invalid certs, not sure how likely this is, though
• When useful, validated certs (or at least their useful evidence) might need to be passed around manually all the way down to the consumer
• Likely a smaller refactor, as we can probably unwrap ValidatedPerasCerts in a couple of places and keep the original type signature

Do you think (1) is the right approach here? Or is (2) something more akin to what we would want at this stage in the dev cycle?

I think (1) is indeed the right approach, the benefits seem compelling even at this stage.

(In the standup, we just briefly talked about some of the implications this has once we store certificates on disk, such as whether we also want to store the weight boost of a certificate on disk, or recompute it on startup. But this is not important for now.)

including the "generation" of the now needed validation evidence in some property tests

This is actually a desired outcome of this change, see the last paragraph in the issue description of #94. To keep this PR minimal, still always using boostPerCert sounds good as you currently do; enriching the generators could be follow-up work.